perm filename MAIL.PRO[DLN,MRC]4 blob
sn#325542 filedate 1977-12-30 generic text, type C, neo UTF8
COMMENT ā VALID 00009 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 Dialnet memo #5
C00004 00003 PREFACE
C00008 00004 INTRODUCTION
C00014 00005 SYNTAX
C00019 00006 GOALS AND NON-GOALS
C00021 00007 MAIL FIELDS
C00024 00008 MAIL COMMANDS
C00028 00009 MAIL COMMANDS (continued)
C00030 ENDMK
Cā;
Dialnet memo #5
SAILON down the muddy Mississippi
Dialnet Protocols
(or, the Protocols of DIAL)
MAIL Protocols
Mark Crispin
12/30/77
These protocols are being developed as part of the Dialnet project at the
Stanford University Artificial Intelligence Laboratory supported by NSF grant
MCS 77-02080 with John McCarthy as Principal Investigator. The project is
described in a paper available online at ARPAnet host SU-AI as
DIALNE.MEM[DLN,MRC] (Dialnet Memo #1).
This is MAIL.PRO[DLN,MRC] at ARPAnet host SU-AI (octal 13, decimal 11.).
PREFACE
"Aren't you glad you use Dialnet? Don't you wish everybody did?"
This document specifies a protocol for use in communication between Host
computers using the Dialnet protocols. In particular, it provides for
transmission of "letters" between hosts. Such letters may take the form of
person-to person communications.
Although self-contained, this document specifies only one of the Dialnet
protocols. In particular, while this protocol specifies the format in which
Dialnet mail is to be transmitted, it does not define how the data link is set
up or how data is transmitted; nor does it define how the mail processor should
display the mail to the user.
This mail protocol is one of the "third level", or tertiary, protocols used
on Dialnet. The primary protocol is the protocol of the dialing modems. The
secondary protocol, or Host-Host protocol, is described elsewhere, as are the
other tertiary protocols.
Questions concerning Dialnet protocols should be addressed to:
Mark Crispin
Stanford Artificial Intelligence Laboratory
Stanford, California 94305
(415) 491-1407
MRC@SU-AI
Copies of all Dialnet-related correspondence should be sent to John
McCarthy (Dialnet principal investigator) and Les Earnest at the above US mail
address or via ARPAnet mail to JMC@SU-AI and LES@SU-AI.
It is the intent of the author that these protocols are both simple in
their implementation and powerful in their operation. Certainly a major design
consideration was to design protocols that ordinary mortals could implement on
their systems.
The intended audience of Dialnet ranges from fairly small to quite large
systems, however, Dialnet has been designed to be nice for medium sized
time-sharing systems, such as PDP-10's and DECsystem-20's.
INTRODUCTION
Dialnet provides a capability for geographically separated users to
communicate with each other via their computer systems. Their local systems
typically differ in how such messages, known as MAIL, should be formatted.
The host-host protocol described in Dialnet memo #2 documents a mechanism
for these hosts to establish an error-free data link between two cooperating
processes.
This protocol, however, is insufficient to specify meaningful communication
between dissimilar mail processes in different hosts. The processes must have
some agreement as to the message formats, etc. While it is possible for
individual pairs of hosts or processes interested in communication with each
other to establish private protocols, it is more desirable for a Dialnet-wide
set of standard message formats to be established to minimize the amount of
implementation effort.
The ARPAnet implements mail as part of the file transfer protocol. This
has some advantages and disadvantages. A short-term advantage of this form of
mailing is that it is relatively simple to implement and interface to an
existing mail system assuming the current mail system already uses the standard
format. In the long term, however, many problems have arisen as increasing
varieties of mail formats have appeared and increasingly hairy mail reading
programs have been written. It no longer became enough for a human to
comprehend a message header in order to determine the sender of the message;
computer programs had to parse headers as well.
It would be short-sighted to assume that this would not happen with Dialnet
mail as well. In addition, the ARPAnet mail formats leave much to be desired.
First, they are in the format of a business memorandum, leading many to the
assumption that a business memorandum was the proper format for message headers
to take.
Second, too much flexibility was allowed in the formats of various items,
with the unfortunate result that too many esoteric varieties of mail commands
ensued, and many trivial arguments over highly esoteric matters developed.
Dialnet mail avoids the problem with multiple formats of message headers by
eliminating them entirely. Instead, messages are sent using a mail protocol.
Each host is only required to implement what parts of the protocol they require
after a certain common minimum subset. If a host wishes to have a message
heading (as well it might, since valuable information such as whom the message
was from is contained therein), it may generate a header in any format.
Keeping this in mind, a method of expressing such information in a clearly
unambiguous and readily machine-parsable way was sought. The LISP syntax of
S-expressions was chosen, due to its extreme versatility.
In the mail protocol, the user sends S-expressions as commands to the
server, which replies in turn using S-expressions. No actual LISP evaluating is
actually done; all that is needed is a "LISP reader" which can recognize an
S-expression and be able to distinguish the CAR and CDR of an expression.
For those unfamiliar with LISP, a brief introduction to the syntax is on
the next page. It is not intended to be a description of LISP syntax, but
rather the "LISPese" syntax used by Dialnet mail.
SYNTAX
The mail protocol consists of an interchange of S-expressions, which are
things inside balanced parenthesis. Parenthesis are special characters in all
cases. In order for them to be included in text, they must be quoted with a
slash (/) character. Hence slash is a special character as well.
Newline is represented by an 012 byte. This is distinct from the "line
feed" character, which does not exist in the mail protocol.
The character set which is legal in the mail protocol consists of all the
printing characters in the 1968 ASCII character set including space (in other
words, the characters whose ASCII value is between 040 and 176) and newline. In
particular, rubout and the "control" characters (some of which are used for text
formatting on some systems) are not part of the protocol and should not be used.
There is no guarantee that the server will interpret these characters in the way
the user intended.
If for some reason "control" characters MUST be sent, it should be noted
that line feed must be quoted since otherwise it would be interpreted as
newline. Again, servers are under no obligation to implement "control"
characters.
There are no other special characters. In particular, whitespace and
newlines within an S-expression are treated as significant in many places. In
non-textual situations, such as delimiting between atomic values, a single
whitespace or newline is required and further whitespace/newlines are
superfluous and should be ignored. However, while mail servers should be
prepared to ignore superfluous whitespace or newlines, it is strictly speaking a
violation of protocol to send superfluous whitespace or newlines.
Some LISP terms need to be defined for the non-LISP user to make the rest
of this document clearer. Within an S-expression, there can be atoms or other
S-expressions. An atom is an indivisible "word". The other S-expressions are
called "lists", as they are not evaluated further.
The CAR of an S-expression or list is the first atom in the list. The CDR
is what remains of the S-expresssion after the CAR has been removed. These two
terms are sometimes combined; the second element of the list is the CAR of the
CDR or the CADR; the third element is the CAR of the CDR of the CDR or CADDR,
etc.
EXAMPLES:
1. FOO is an atom
2. (FOO BAR) is a list
3. (FOO BAR GARPLY) is a list
4. (FOO BAR (BAZ GARPLY)) is a list
5. FOO is the CAR of #2, #3, and #4
6. (BAR (BAZ GARPLY)) is the CDR of #4
7. BAR is the CAR of #6
8. (BAZ GARPLY) is the CDR of #6
9. FOO/ BAR is an atom!!
GOALS AND NON-GOALS
1. To avoid repeating the mistakes of ARPAnet mail.
2. To have a system that is simple to implement.
3. To establish strict mail formats with no ambiguity of format, to prevent the
proliferation of mail header formats which has occured in the ARPAnet.
4. To allow the mail sender complete freedom in what is included in the actual
body of the mail message.
5. To abolish mail headers as they exist in current mail systems entirely.
6. To replace the information formerly contained in the mail header with a mail
protocol negotiation.
The following are currently non-goals. It is felt that there is no
justification at the present time to consider these matters.
1. Compatability with ARPAnet mail.
2. Message security or encryption. This may happen later.
3. Explicit forwarding.
4. Detection and deletion of duplicate copies of a message or of mail loops.
MAIL FIELDS
*** NOTE ***
In all mail fields, it is STRONGLY SUGGESTED that either upper or lower
case be accepted, and that lower case be converted to upper case for machine-
reading purposes. In addition, the official case for protocol commands is upper
case; however, a server must not depend upon only receiving upper case. A
server that fails to do case-independent matching is bound to encounter problems
in interfacing with other systems.
The fields or arguments to a mail protocol command are one of the
following:
ADDRESS -- an atom or list which specifies a valid machine-readable mail
address on the host in question.
HOST-IDENTIFICATION -- either phone-number or a list whose CAR is
phone-number and whose CADR is host-name.
HOST-NAME -- an atom which specifies the official host name as kept on
record by the Dialnet implementors.
MESSAGE-TEXT -- a text string consisting of the actual text of the message.
PHONE-NUMBER -- a dialup phone number in the form of a string of digits.
SUBJECT-TEXT -- an optional text string used as a one-line "topic" of the
message.
TEXT -- a data type (see SUBJECT-TEXT and MESSAGE-TEXT) which is completely
quoted. TEXT outwardly looks like a list in that there are parentheses at each
end, and parentheses and slashes must be quoted with slash; however, whitespace
and new lines are significant and are not converted to something else by the
mail process.
MAIL COMMANDS
The commands on these pages are the more important commands of the mail
protocol which all servers are expected to implement.
For all mail commands, the reply (FAILED) is used to indicate a command
that failed due to some internal bug on the part of the server, for such things
as string space exhausted or the like. This code is NOT intended to be used to
indicate a user error.
I. (TO address)
This is the most important command in the mail protocol, and the only
required one. It specifies to whom the message is to be sent. The address must
be a legal address for the server site; ie, it must be machine-readable as
opposed to a "human" address.
Examples:
(TO MRC)
(TO Network/ Wizard)
Replies:
(OK)
The address has been accepted. More destinations may be specified for
this message.
(OK-NO-MORE)
The address has been accepted, but no more destinations may be
specified for this message.
(UNKNOWN)
The address has been rejected; there is no known destination at this
site with that address.
(ILLEGAL)
The address is in illegal format for this site.
II. (FROM address host-identification)
This command specifies the origin of the message. The address must be a
legal address for the user site's mail server; ie, it must be machine-readable.
The address in this command is the default for the SENDER and REPLY-TO
addresses. It should be noted that many sites may not wish to implement SENDER
and REPLY-TO. This means that FROM is required if any origin is specified at
all, and that it should specify a reasonable origin and reply address.
Examples:
(FROM MRC 415-497-1234)
(FROM DIALNET-HACKER (415-497-4321 SU-AI))
Replies:
(OK)
The command was accepted. This is the only legal response.
MAIL COMMANDS (continued)
III. (SUBJECT subject-text)
This command specifies a subject text for the message. It is used to
provide a short topic for the message for the reference or filing purposes of
the eventual message reader.
Examples:
(SUBJECT (Suggested addition to the MAIL protocol))
(SUBJECT (In reply to your message about the MAIL protocol))
Replies:
(OK)
The command was accepted. This is the only legal response.
IV. (MESSAGE message-text)
This command specifies the text body of the message.
Example:
(MESSAGE (It has been suggested that the MAIL protocol be enhanced
to make the phase of the moon be a required item in all
messages. It is felt that this item is very important
and all user and server programs will be expected to
implement this by next Tuesday.
))
Replies:
(OK)
The command was accepted. This is the only legal response.